Would it be possible to avoid the side effect of delaying the PEP 765 syntax warnings to the code generation stage? Emitting those syntax warnings during AST construction is one of the key reasons I was comfortable suggesting turning them off globally in #139658 when static code analysis was in use.

Only if you are fine with double warnings in REPL or other places that use ast.parse() + compile() instead of just compile().

There are three kinds of warnings, by the emitter:

• Emitted in the lexer/tokenizer. They are always emitted when you parse the Python sources.
• Emitted in the AST optimizer. They may be emitted twice, in ast.parse() and compile(). Currently, this is only the PEP 765 warnings.
• Emitted in the code generator. They are only emitted if you use compile().

So, you already see not all warnings if you only use ast.parse(), without code generation. The fact that the PEP 765 warnings are emitted in the AST optimizer instead of the code generator is just an implementation detail. It could perhaps even be more convenient to emit them in the code generator.

The fact that the PEP 765 warnings are emitted in the AST optimizer instead of the code generator is just an implementation detail.

Actually I think this was a deliberate decision, we want this to happen during static analysis.

Can we add a kwarg to ast.parse to tell it whether to emit syntax warnings or not?

We can, but

• This is a new feature. It can perhaps be backported to 3.14.1 as a special exception.
• Every user of ast.parse() and compile() will need to modify their code to pass the new option. And they will not get all warnings, they will only get the PEP 765 warning. Is it worth a new option?

It is safer to disable that warning by default in ast.parse().

Every user of ast.parse() and compile() will need to modify their code to pass the new option. And they will not get all warnings, they will only get the PEP 765 warning.

The default should be to give the warning. Turn it off in cpython when we know that the code was just ast.parse'ed (rather than an ast given by the user - we do know that).

What is the name of the option you propose to add?

Could be with_warnings or something like that.

No, because it should not control all warnings. Maybe _enable_pep_765_warnings?

This would complicated, and I need to revert #131993 because it is a blocker for my other changes.

See yet one option in #139719. It is based on the original solution by @tomasr8.

Why not all warnings?